Kommunikasjon mellom Micro-Frontends: Event Bus og meldingsutveksling

I moderne webutvikling har micro-frontend-arkitektur blitt en kraftig løsning for å bygge skalerbare og vedlikeholdbare applikasjoner. Ved å bryte ned en stor frontend-monolitt i mindre, uavhengige enheter, kan team jobbe autonomt, deployere uavhengig og bruke forskjellige teknologier for hver micro-frontend. Denne distribuerte naturen introduserer imidlertid en ny utfordring: hvordan legge til rette for kommunikasjon mellom disse uavhengige komponentene. Det er her teknikker som event bus og meldingsutveksling kommer inn i bildet.

Hva er Micro-Frontends?

Før vi dykker ned i kommunikasjonsstrategier, la oss definere hva micro-frontends er. Micro-frontends er i hovedsak uavhengig deployerbare og vedlikeholdbare frontend-applikasjoner, ofte bygget av forskjellige team. De kan bruke forskjellige teknologier (f.eks. React, Angular, Vue.js) og settes sammen ved kjøretid, byggetid eller til og med ved brukerinteraksjon.

Sentrale kjennetegn ved micro-frontends inkluderer:

• Uavhengig deployering: Hver micro-frontend kan deployeres uten å påvirke andre deler av applikasjonen.
• Teknologiuavhengig: Ulike micro-frontends kan bygges med forskjellige teknologier.
• Autonome team: Ulike team kan eie og utvikle forskjellige micro-frontends.
• Kodeisolasjon: Endringer i én micro-frontend skal ikke ødelegge for andre micro-frontends.

Behovet for kommunikasjon mellom Micro-Frontends

Selv om uavhengighet er en sentral fordel med micro-frontends, må de ofte kommunisere med hverandre. Denne kommunikasjonen kan ha ulike formål, som for eksempel:

• Datadeling: Sende data mellom micro-frontends (f.eks. brukerprofilinformasjon, produktdetaljer).
• Utløse handlinger: Én micro-frontend kan trenge å utløse en handling i en annen (f.eks. oppdatere en handlekurv, vise en varsling).
• Tilstandssynkronisering: Opprettholde en konsistent tilstand på tvers av flere micro-frontends (f.eks. autentiseringsstatus, brukervalg).
• Navigasjon og ruting: Koordinere navigasjon mellom ulike deler av applikasjonen, som potensielt håndteres av forskjellige micro-frontends.

Uten en veldefinert kommunikasjonsstrategi kan micro-frontends bli isolerte siloer, noe som svekker brukeropplevelsen og gjør den helhetlige applikasjonen vanskelig å administrere. Derfor er det avgjørende å etablere pålitelige og effektive mekanismer for kommunikasjon mellom micro-frontends.

Kommunikasjonsstrategier: Event Bus og meldingsutveksling

Flere kommunikasjonsmønstre kan brukes i en micro-frontend-arkitektur. Dette innlegget fokuserer på to mye brukte tilnærminger: Event Bus og meldingsutveksling.

1. Event Bus

Event Bus-mønsteret er en publiser-abonner-mekanisme som lar micro-frontends kommunisere uten direkte avhengigheter til hverandre. I dette mønsteret publiserer micro-frontends hendelser (events) til en sentral event bus, og andre micro-frontends abonnerer på spesifikke hendelser. Når en hendelse publiseres, mottar alle abonnenter en varsling.

Slik fungerer det:

1. Definisjon av hendelser: Definer et sett med hendelser som micro-frontends kan publisere og abonnere på. Disse hendelsene bør ha veldefinerte datastrukturer (payloads).
2. Implementering av Event Bus: Implementer en sentral event bus. Dette kan være et enkelt JavaScript-objekt eller et mer sofistikert bibliotek som Mitt, rfdc, eller en egendefinert implementasjon.
3. Publisering av hendelser: Micro-frontends publiserer hendelser til event bus-en når bestemte handlinger skjer.
4. Abonnering på hendelser: Micro-frontends abonnerer på hendelser de er interessert i. Når en hendelse publiseres, varsler event bus-en abonnentene, og de kan håndtere hendelsen deretter.

Eksempel (med Mitt):

            
// Opprett en event bus
import mitt from 'mitt';
const emitter = mitt();

// Micro-frontend A (utgiver)
function publishProductAdded(product) {
  emitter.emit('product:added', product);
}

// Micro-frontend B (abonnent)
function handleProductAdded(product) {
  console.log('Produkt lagt til:', product);
  // Oppdater handlekurv, vis varsling, etc.
}

emitter.on('product:added', handleProductAdded);

// Bruk i Micro-frontend A:
publishProductAdded({ id: 123, name: 'Eksempelprodukt', price: 19.99 });

            

              
                Copy
              
            
          

Fordeler med Event Bus:

• Løs kobling: Micro-frontends trenger ikke å kjenne til hverandre. De samhandler kun med event bus-en.
• Skalerbarhet: Nye micro-frontends kan enkelt legges til uten å påvirke eksisterende.
• Fleksibilitet: Micro-frontends kan dynamisk abonnere og avbryte abonnement på hendelser etter behov.

Ulemper med Event Bus:

• Potensial for hendelseskollisjoner: Hvis hendelser ikke er veldefinerte, er det en risiko for navnekollisjoner. Det er avgjørende å implementere en tydelig navnekonvensjon og et hendelsesskjema.
• Kompleks feilsøking: Å spore flyten av hendelser kan være utfordrende, spesielt i store applikasjoner. Vurder å bruke logging eller feilsøkingsverktøy for å spore hendelser.
• Ytelseskostnad: Overdreven publisering av hendelser kan påvirke ytelsen. Optimaliser hendelsesfrekvensen og størrelsen på payload.
• Mangel på garantert levering: Hendelser kan gå tapt hvis abonnenter ikke lytter på publiseringstidspunktet.

2. Meldingsutveksling

Meldingsutveksling innebærer direkte kommunikasjon mellom micro-frontends ved hjelp av teknikker som `window.postMessage`. Dette gjør at én micro-frontend kan sende en melding til en annen, rettet mot en spesifikk opprinnelse (domene eller underdomene).

Slik fungerer det:

1. Meldingsdefinisjon: Definer strukturen på meldingene som micro-frontends vil utveksle. Hver melding bør ha en `type`-egenskap for å identifisere formålet med meldingen og en `payload`-egenskap som inneholder dataene.
2. Sende meldinger: Én micro-frontend sender en melding til en annen ved hjelp av `window.postMessage`. Meldingen inkluderer meldingstype, payload og målets opprinnelse (target origin).
3. Motta meldinger: Den mottakende micro-frontend-en lytter etter `message`-hendelser på `window`-objektet. Når en melding mottas, sjekker den opprinnelsen og meldingstypen for å bestemme hvordan den skal håndteres.

Eksempel:

            
// Micro-frontend A (avsender)
function sendMessageToB(message) {
  const targetOrigin = 'https://microfrontend-b.example.com';
  window.postMessage(message, targetOrigin);
}

// Eksempelmelding:
const message = {
  type: 'user:updated',
  payload: { id: 1, name: 'Ola Nordmann' },
};

// Send meldingen
sendMessageToB(message);

// Micro-frontend B (mottaker)
window.addEventListener('message', (event) => {
  // Valider opprinnelsen for å forhindre sikkerhetssårbarheter
  if (event.origin !== 'https://microfrontend-a.example.com') {
    return;
  }

  const message = event.data;

  if (message.type === 'user:updated') {
    console.log('Bruker oppdatert:', message.payload);
    // Oppdater brukerprofil, vis varsling, etc.
  }
});

            

              
                Copy
              
            
          

Fordeler med meldingsutveksling:

• Direkte kommunikasjon: Gir en direkte kanal mellom micro-frontends, noe som kan være mer effektivt for visse bruksområder.
• Målrettede meldinger: Meldinger sendes til en spesifikk opprinnelse, noe som reduserer risikoen for utilsiktede mottakere.
• Enkel implementering: Relativt enkelt å implementere ved hjelp av innebygde nettleser-APIer.

Ulemper med meldingsutveksling:

• Tett kobling: Micro-frontends må kjenne opprinnelsen til den andre micro-frontend-en de kommuniserer med.
• Sikkerhetshensyn: Det er avgjørende å validere opprinnelsen til innkommende meldinger for å forhindre cross-site scripting (XSS)-sårbarheter.
• Kompleksitet i komplekse scenarier: Å håndtere flere meldingskanaler kan bli komplekst etter hvert som antallet micro-frontends øker.
• Feilhåndtering: Det kan være vanskeligere å håndtere feil og sikre pålitelig meldingslevering sammenlignet med mer robuste meldingssystemer.

Velge riktig kommunikasjonsstrategi

Valget mellom Event Bus og meldingsutveksling avhenger av de spesifikke kravene til applikasjonen din. Her er en sammenligning for å hjelpe deg med å bestemme:

Vurder disse faktorene når du tar din avgjørelse:

• Grad av kobling: Hvis du trenger løst koblede micro-frontends, er Event Bus et bedre valg. Hvis du trenger direkte kommunikasjon mellom spesifikke micro-frontends, kan meldingsutveksling være mer egnet.
• Krav til skalerbarhet: Hvis du forventer et stort antall micro-frontends, er Event Bus generelt mer skalerbar.
• Sikkerhetshensyn: Begge tilnærmingene krever nøye sikkerhetsvurderinger. Sørg for korrekt definisjon av hendelser og validering av opprinnelse for å forhindre sårbarheter.
• Kompleksitetstoleranse: Vurder kompleksiteten ved å implementere og vedlikeholde hver tilnærming. Start med den enkleste løsningen som oppfyller dine behov.

Beste praksis for kommunikasjon mellom Micro-Frontends

Uavhengig av hvilken kommunikasjonsstrategi du velger, vil følgende beste praksis bidra til å sikre en robust og vedlikeholdbar micro-frontend-arkitektur:

• Definer en tydelig kommunikasjonsprotokoll: Etabler en klar og veldokumentert kommunikasjonsprotokoll som definerer strukturen til hendelser eller meldinger. Dette vil bidra til å sikre konsistens og forhindre feil.
• Bruk versjonering: Versjoner hendelsene eller meldingene dine for å sikre kompatibilitet etter hvert som dine micro-frontends utvikler seg. Dette lar deg introdusere endringer uten å ødelegge eksisterende integrasjoner.
• Implementer feilhåndtering: Implementer robuste mekanismer for feilhåndtering for å håndtere kommunikasjonsfeil på en elegant måte. Dette inkluderer logging av feil, forsøk på nytt ved feil, og å gi tilbakemelding til brukeren.
• Overvåk kommunikasjonen: Overvåk kommunikasjonen mellom micro-frontends for å identifisere ytelsesflaskehalser og potensielle problemer. Bruk logging og metrikker for å spore frekvens, forsinkelse og feilrater for hendelser eller meldinger.
• Prioriter sikkerhet: Prioriter alltid sikkerhet når du implementerer kommunikasjon mellom micro-frontends. Valider opprinnelsen til innkommende meldinger, saner data og bruk sikre kommunikasjonskanaler (f.eks. HTTPS).
• Dokumenter alt: Dokumenter micro-frontend-arkitekturen din grundig, inkludert kommunikasjonsprotokoller, hendelsesskjemaer og meldingsformater. Dette vil bidra til at teamet ditt kan forstå og vedlikeholde systemet over tid.

Alternative kommunikasjonsstrategier

Selv om Event Bus og meldingsutveksling er vanlige, finnes det også andre tilnærminger for kommunikasjon mellom micro-frontends:

• Delt tilstandshåndtering (f.eks. Redux, Vuex): Et sentralt lager (store) tilgjengelig for alle micro-frontends. Dette krever nøye administrasjon for å unngå konflikter.
• Web Components: Bruk av egendefinerte HTML-elementer for å innkapsle micro-frontends og definere tydelige grensesnitt.
• Backend for Frontend (BFF): Hver micro-frontend kommuniserer med sin egen dedikerte backend-tjeneste, som deretter koordinerer kommunikasjonen.
• Custom Events: Sende og lytte til egendefinerte hendelser på DOM-en.

Konklusjon

Effektiv kommunikasjon er avgjørende for en vellykket micro-frontend-arkitektur. Ved å forstå styrkene og svakhetene ved ulike kommunikasjonsstrategier som Event Bus og meldingsutveksling, kan du velge den rette tilnærmingen for dine spesifikke behov. Husk å følge beste praksis for sikkerhet, feilhåndtering og dokumentasjon for å sikre et robust og vedlikeholdbart system. Ettersom landskapet for micro-frontends fortsetter å utvikle seg, vil det være avgjørende å utforske alternative kommunikasjonsmønstre og holde seg oppdatert på de nyeste trendene for å bygge skalerbare og tilpasningsdyktige webapplikasjoner. Ta hensyn til globale målgrupper og varierende nettverksforhold når du designer kommunikasjonsmønstre, og velg tilnærminger som minimerer dataoverføring og maksimerer robusthet. Implementer overvåking og varsling for proaktivt å identifisere og løse kommunikasjonsproblemer som kan påvirke brukeropplevelsen, spesielt i regioner med mindre pålitelig infrastruktur.